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Abstract 

This paper will help you to design the 3 -tier public key infrastructure for your organization. 
Focus is to build the understanding of the major components of entire architecture and their 
configuration considerations. 



2 Executive Summary 

A PKI will provide you a flexible, extensible security foundation that it can leverage to solve 
many information security problems. The model that is chosen uses a tree tier certificate 
authority (CA) model running locally in a data center. This document describes the overall 
technical architecture. Introduction 

2.1 Document Purpose 

This document describes the design of certificate authorities and management systems. It is 
intended to assist information security department that wish to leverage PKI. The intended 
audience of this document is: 

• Information Security Officers 

• System Engineers 

2.2 Document Scope 

• Physical infrastructure 

• Logical infrastructure 

• Technologies used 

• High level configuration 

2.3 Exclusions 

This document specifically excludes the following: 

• Application design or integration questions, beyond a discussion of the standards and 
interfaces supported by the PKI 

• Deployment or operational details 

• The companion documents, Certificate Practice Statement and Certificate Policy, 
describe the processes used to commission and manage the PKI. 



3 Architecture 

The certificate authority (CA) hierarchy utilizes a three tier design with a standalone offline root 
CA, standalone offline policy CA and an online enterprise issuing CA. This design fulfils all 
stated goals for the project, provides immediate capability for the following types of certificates, 

• Encrypting File System (EFS) 

• Secure/Multipurpose Internet Mail Extensions (S/MUVIE), 

• Multifactor authentication such as smart cards 

• IPSec 

• Digital signature 

• RADIUS and 802. lx authentication 

• Wireless network authentication using Wi-Fi Protected Access (WPA) or Wi-Fi Protected 
Access 2 (WPA2) 

• NAP (Network Access Control) and NAQ (Network Access Quarantine) 

• Code and driver signing 

• SSL/TLS for protecting HTTP based traffic 

And provides significant capacity for future needs you may wish to use the system for. The root 
tier forms the core trust anchor in the hierarchy. In other words, the trust relationship of all 
certificates issued by a CA in the hierarchy eventually chain up to the root CA. The root CA 
forms the common bond between all CAs and certificates in the hierarchy. The root CA issues 
certificates only to policy and issuing CAs that have demonstrated compliance with its security 
and certificate policies. 

A policy CA is the second-tier of a CA hierarchy, directly beneath the root CA. The root CA 
issues a Subordinate Certification Authority certificate to the policy CA. The role of a policy CA 
is to describe the policies and procedures that you can implement to secure the PKI, the 
processes that validate the identity of certificate holders, and the processes that enforce the 
procedures that manage certificates. A policy CA issues certificates to the issuing CAs. The 
issuing CA upholds and enforces the policies that the policy CA defined. 
The issuing CA is online and available on the network. This is an end entity facing system 
responsible for providing certificates to the user and machine population. Its certificate is signed 
by the Policy CA above it in the hierarchy and it issues certificates that chain through itself to the 
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root CA. 

From a growth standpoint, you can easily add additional capacity to the hierarchy by simply 
commissioning new enterprise CAs following the same process used in this design. You may 
wish to host a CA offsite for disaster recovery purposes. If this need arises, you again need only 
follow the provisioning process from this design, and can place CAs at any remote datacenter 
location you desire. 




PKI components table 



Component 


Description 


Certification 
Authority 


Root CA, that acts as the root of trust in a public key infrastructure and 
provides services that authenticate the identities in the network. 


Registration 
Authority 


Issuing CA (Online Subordinate CA) that is certified by a root CA to issue 
certificates for specific uses permitted by the root. 


Certificate 
Database 


nShield and netHSM save certificate requests and issued and revoked 
certificates. 


Key Archival 
Server 


nShield and netHSM save encrypted private keys in the certificate database 
for recovery after loss. 
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Standalone 
Offline Root CA 
with nShleld 



Standalone 
Offline Policy CA 
with nShleld 



Enterprise 
Online RA 
with netHSM 





netHSM 



Shield 



3.1 Qualified Subordination 

Qualified subordination allows cross-certification of CA certificates with name constraints and 
provides for more precise control of certificate trusts. With qualified subordination, you can 
include or exclude certificate purposes or naming suffixes when federating with other entities. 
This design does not utilize qualified subordination to constrain the types of certificates that can 
be used within the hierarchy. If, in the future, you wish to federate your PKI with another 
organization, such as the business partner, sister concern or any other PKI, qualified 
subordination and cross certification could be used to facilitate this integration. 

3.2 CA Operating System 

There are numerous new capabilities in the Windows Server 2008 Certificate Authority service, 
including Suite B algorithms of NSA, new wizard-based enrollment tool, version 3 templates, 
strong authentication, and Best Practices Analyzer (BP As). We choose to use Windows Server 
2008, Enterprise Edition with as the operating system for its all PKI components. Each instance 
of Windows Server 2008 used as a CA should be hardened with Security Configuration Wizard 
(SCW) 2008. 



3.3 CA Server Hardware 

Microsoft performance testing has shown that the signing key length of the CA has the most 
significant impact on the potential enrollment rate of the CA. A larger number of certificates can 
be signed and enrolled in a given time if a smaller key size is used. If a larger key size is used, 
more CPU time is required to issue each certificate. The total number of issued certificates 
should not have a significant influence on either server performance or the rate at which the CA 
issues certificates. The performance of the issuing CA stays nearly the same whether thousands 
or millions of certificates have previously been issued. Therefore, the scalability of the CA is 
considered to be linear, based on the size and performance of the disks that are used to store both 
the database and log files. 

All CAs are built on the SunFire X4200 M2 Powered by Dual-Core AMD Opteron processors, 
8GB of RAM, and 70GB of high performance 2.5-inch SAS disks with integrated hardware raid 
controller for Root and Policy CA. And Sun Blade X6250 Server Modules Powered by Intel 
Xeon Processors, 16GB of RAM, and 140GB of high performance 2.5-inch SAS disks with 
integrated hardware raid controller for Issuing CA. 

3.4 CA Availability 

When considering redundancy within the PKI, it is important to keep in mind that clients will 
only need to communicate with Issuing CA during certificate issuance and certificate renewal. 
Certificate users do not contact the CA on an ongoing basis and do not require its availability to 
utilize certificates it has issued. As such, even in a worst case scenario where CA was 
completely offline, the user impact should be minimal (assuming service is restored prior to the 
end of the CRLs' validity lifetime), as the only failures from this scenario would be users or 
computers that need to have certificates created or renewed. Existing users or machines with 
currently valid certificates would likely not even be aware of the outage. 

3.5 Active Directory Considerations 

Active Directory environment was already prepared to integrate with a Windows Server 2008 
enterprise CA because its schema domain controllers were already running Windows Server 
2008. Issuing CA will be the member server in forest root domain. 
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4 Security Design 

4.1 Hardware Security Modules 

An HSM (Hardware Security Module) is a dedicated hardware device that is managed separately 
from the operating system. These modules work with servers to provide a secure hardware store 
for CA keys. From an operating system view through the CryptoAPI and MS CNG interfaces, 
the HSM is seen as a cryptographic service provider (CSP) device. The HSM provides highly 
secure operational management that is protected by multilayered hardware and software tokens, 
as well as a number of other key features, including: 

• Hardware -based, cryptographic operations, such as random number generation, key 
generation, and digital signatures, as well as key archival and recovery. 

• Hardware protection of valuable private keys that are used to secure asymmetric 
cryptographic operations. 

• Secure management of private keys. 

• Acceleration of cryptographic operations, which relieves the host server of having to 
perform processor-intensive, cryptographic calculations. 

In the test design, we are using the following given HSMs 

• Model: nCipher nShield PCI Express F3 6000e (Direct Attached) 

Host Interface= PCI Express x8 lane, Base Specification 1.1 (SunFire X4200 M2) 

• Model : nCipher netHSM 2000 with SEE and Smart Card Features Plus 8 Smart Cards 
The HSMs are FIPS 140-2 level 3 device and support K of N protection of the keying material. 

4.2 Physical Security 

As with any sensitive information asset, the certificate authorities should be kept in a physically 
secure datacenter that utilizes the strong physical controls. Controls include finger scanner based 
access control system and video surveillance. 

4.3 Authentication and Authorization 

A CA running Windows Server 2008, Enterprise Edition uses DCOM and Kerberos 
impersonation for authenticating requesters. It compares the client token against an access 
control list (ACL) set on the certificate template, as well as the DCOM enrollment interface on 
the CA itself, when a certificate is requested. This allows creating templates that only certain 
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users or computers, based on normal Windows group membership, have access to. All requests 
for certificates for users or computers that are not part of Active Directory will be made through 
an SSL encrypted web portal. This portal will authenticate users against their Active Directory 
accounts and provide a self-service mechanism for requesting and obtaining certificates. For 
users from other organizations, you can create a 'sponsored' account for them within the Active 
Directory expressly for certificate management functionality. 

4.4 Auditing 

Certificate authority will log important events as they occur within the environment. 
Specifically: 

• Backup and restores of any key data 

• CA configuration changes 

• CA security or rights changes 

• The actions of issuing, managing or revoking certificates 

• Key storage and key retrieval 

• Server/service start and stop 

The Information Security Department and PKI Admins will be the primary recipient of these 
logs and will act on them as necessary. These logs will be kept for 30 days, except in cases 
where the Office determines greater retention lengths are necessary. 

4.5 CA Key Lengths and Lifetimes 

The following table describes key lifetimes and private key renewal strategies in test 
environment. 



Purpose of Certificate 


Key size (bits) 


Algorithms 


CA Cert Expiration 


Root CA 


4096 


RSA and SHA- 
512 


20 Years 


Policy CA 


4096 


RSA and SHA- 
512 


10 Years 


Issuing CA 


2048 


RSA and SHA- 
512 


01-02 Year(s) 


End entities 


1024-2048 




01 Month - 1 Year 
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5 Certificate Lifecycle Management 

Microsoft Forefront Identity Manager (Identity Lifecycle Manager "2") is used for Certificate 
Policy and Lifecycle Management. 

5.1 Enrollment Methods 

Three types of enrollments method are available to get the Digital Certificates for user, service 
and network devices. 

5.1.1 Web Enrollment Method 

The ILM Portal service is running over SSL (1024 Bits) and with password protection on 

the CA server and the web request feature installed and enabled. 

The Web enrollment interface enables users to perform the following tasks: 

• Request a certificate from the CA 

• Request the certificate revocation list (CRL) of the CA 

• Request the certificate of the CA 

• Check the status of a pending certificate request 

• The Web enrollment interface can also be used for smart card certificate enrollment 



URL: http://issuingca-fqdn/pki/cert 
5.1.2 Manual Enrollment Method 

Manual certificate enrollment occurs using the Certificates snap-in, the Certreq.exe 
command-line utility, or the Web based interface. 

• The Certificates snap-in: To use the Certificates snap-in to submit certificate 
requests to the CA, user needs the Microsoft Management Console (MMC) snap-in. 
The snap-in includes the Certificate Request Wizard which guides through the 
certificate enrollment process. 

• The Certreq.exe command- line utility: Command-line utility enables to script 
the certificate enrollment process. 

• The Web enrollment process: This is the simplest method which end users can 
use to request certificates from the CA. Contains Active Server Pages and ActiveX 
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controls that provide a Web-based user interface to a CA over SSL. 

5.1.3 Auto Enrollment Method (Network Devices Enrollment Service) 

NDES implements the Simple Certificate Enrollment Protocol (SCEP) and different types 

of digital certificate templates are configured for each request type. NDES also supports 
the renewal of certificate. The Enrollment challenge password that is valid up to 60 
minutes is used for authentication and thumbprint of CA certificate will be passed to 
network device to validate the CA certificate. 
URL: http://issuingca-fqdn/pki/ndes 

5.2 Certificate Request Approval 

When a certificate request reaches a CA that is running a member of the Windows Server 2008 
family, the CA can immediately issue the certificate or put it into a pending state. It is the 
responsibility of the CA administrator to configure the enrollment method either globally for a 
CA or on a per-template basis. For a Windows Server 2008, Enterprise Edition enterprise CA 
the enrollment method can be set individually for a V2 and V3 template. 
The Windows SMTP exit module will be configured to automatically send email to the PKI 
Admins when a certificate request that requires approval is submitted. The Admin will establish 
and communicate an Operational Level Agreement (OLA) for acting upon these requests, likely 
within 24 hours. 

5.3 Key Archival / Recovery 

Key recovery implies that the private key portion of a public-private key pair may be archived 
and recovered. Private Key recovery does not recover any data or messages; it merely enables a 
user to retrieve lost or damaged keys. Each HSM supports key archival, a process where the CA 
can store a copy of private keys. You can choose what certificates should use archival on per 
template, or even a per CA basis. Given the types of certificates used in the initial design, key 
archival is enabled on specific certificate templates as necessary. 

Two Key Recovery Agent certificates are burned on smart card and Key Recovery Agent 
certificates public keys are used to encrypt private key during archival process. 

5.4 Revocation Strategy 

Each certificate created will have a validity lifetime associated with it. From time to time, 
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though, you will need to invalidate certain certificates prior to the end of their validity period. 
For example, if an employee is given a certificate with a validity period that expires in December 
2009, but that employee leaves the organization in August 2009, you would want to mark that 
certificate as invalid. This type of revocation is commonly accomplished with the use of 
Certificate Revocation Lists (CRLs). 

Issuing CA publishes CRL through an HTTP URL that points to a location on a Web server. 
URL: http://issuingca-fqdn/pki 



CRL publishing time table 



CA 


CRL Publishing Time 


Root CA 


1 Year 


Policy CA 


1 Year 


Issuing CA 


24 Hour 



5.5 Renewal Strategy 

For renewal, all the enrollment interfaces can be used. Either existing primary key can be used to 
get the new digital certificate or the new one. User will get a warning message one month before 
the expiration date. 

5.6 Delta CRLs 

The CRL is traditionally a single flat file that grows more or less linearly as additional 
certificates are revoked. Issuing CAs will publish delta CRLs 6 hour and a base CRL every 24 
hours. You should adhere to the following best practices regarding management and usage of 
delta CRLs: 

• Do not use delta CRLs with offline CAs 

• Use delta CRLs with all issuing CAs (the bottom tier of the hierarchy). 
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6 Conclusion 



Architecture is ready, based on windows server 2008 edition just plug your servers and go for 
installations and configuration. If you are not familiar with PKI configuration then I'll 
recommend you to buy and study Mr. Komar's book by MS Press. 
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